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Abstract 

A  new  type  of  system  for  testing  trigger  conditions  and  running  trigger  actions  outside  of  a  DBMS 
was  designed  as  part  of  this  project.  Such  a  system  is  called  an  asynchronous  trigger  processor 
since  it  processes  triggers  asynchronously,  after  triggering  updates  have  committed  in  the  source 
database.  The  architecture  of  a  prototype  asynchronous  trigger  processor  called  TriggerMan  is 
described.  TriggerMan  is  designed  to  be  able  to  gather  updates  from  a  wide  variety  of  sources, 
including  relational  databases,  object-relational  databases,  legacy  databases,  flat  files,  the  web,  and 
others.  TriggerMan  achieves  the  ability  to  gather  updates  from  so  many  sources  using  an 
extensible  data  source  mechanism.  TriggerMan  can  make  use  of  the  asynchronous  replication 
features  of  commercial  database  products  to  gather  updates.  When  cooperating  with  a  source 
DBMS  with  direct  support  for  asynchronous  replication,  TriggerMan  can  gather  updates  in  an 
efficient  and  robust  manner.  TriggerMan  supports  simple,  single-table  (single  data-source) 
triggers,  as  well  as  sophisticated  multiple-table  (multiple-data-source)  triggers.  It  also  will  support 
temporal  triggers  using  an  extensible  temporal  function  mechanism.  Moreover,  TriggerMan  takes 
advantage  of  parallelism  for  high  performance,  utilizing  a  shared-nothing  model  of  parallel 
computation. 

1.  Introduction 

The  main  goal  of  this  project  was  to  develop  technology  to  support  efficient  trigger 
processing  for  shared-nothing  parallel  database  management  systems.  Mid-way  through 
the  one-year  period  of  the  grant,  the  design  and  implementation  focus  of  the  project 
shifted  away  from  developing  trigger  extensions  for  the  Paradise  parallel  DMBS,  toward 
developing  an  independent  system,  an  “asynchronous  trigger  processor”  called 
TriggerMan  [Hans97b].  This  shift  was  brought  on  because  it  was  not  possible  for  us  to 
get  full  source  code  for  the  Paradise  DBMS  from  Wisconsin.  Focusing  effort  on 
TriggerMan  instead  of  Paradise  was  fully  consistent  with  the  original  goals  of  the  project, 
since  TriggerMan  is  also  a  parallel  trigger  processing  system.  In  fact,  the  shift  was 


beneficial  in  terms  of  the  potential  for  technology  transfer,  since  the  prototype  we 
develop  will  be  usable  with  existing  information  systems  applications  built  using  current 
commercial  database  systems.  The  rest  of  this  final  report  covers  the  design  of 
TriggerMan,  our  goals  for  its  future  implementation,  and  plans  for  developing  technology 
to  support  parallel  asynchronous  trigger  processing. 

There  has  been  a  great  deal  of  interest  in  active  database  systems  over  the  last  ten 
years.  Many  database  vendors  now  include  active  database  capability  (triggers)  in  their 
products.  Nevertheless,  a  problem  exists  with  many  commercial  trigger  systems  as  well 
as  research  efforts  into  development  of  database  triggers.  Most  work  on  database 
triggers  follows  the  event-condition-action  (ECA)  rule  model.  In  addition,  trigger 
conditions  are  normally  checked  and  actions  are  normally  run  in  the  same  transaction  as 
the  triggering  update  event.  In  other  words,  the  so-called  immediate  binding  mode  is 
used.  The  main  difficulty  with  this  approach  is  that  if  there  are  more  than  a  few  triggers, 
or  even  if  there  is  one  trigger  whose  condition  is  expensive  to  check,  then  update 
response  time  can  become  too  slow.  A  general  principle  for  designing  high-throughput 
transaction  processing  (TP)  systems  put  forward  by  Jim  Gray  can  be  paraphrased  as 
follows:  avoid  doing  extra  work  that  is  synchronous  with  transaction  commit  [Gray93]. 
Running  rules  just  before  commit  violates  this  principle. 

Moreover,  many  advances  have  been  made  in  active  database  research  which  have 
yet  to  show  up  in  database  products  because  of  their  implementation  complexity,  or 
because  of  the  expense  involved  in  testing  sophisticated  trigger  conditions.  For  example, 
sophisticated  discrimination  networks  have  been  developed  for  testing  rule  conditions 
[Hans96],  In  addition,  techniques  have  been  developed  for  processing  temporal  triggers 
(triggers  whose  conditions  are  based  on  time,  e.g.  an  increase  of  20%  in  one  hour). 
Neither  of  these  approaches  has  been  tried  in  a  commercial  DBMS. 

In  this  report,  the  author  proposes  a  new  kind  of  system  called  an  asynchronous 
trigger  processor,  or  ATP.  An  ATP  is  a  system  that  can  process  triggers  asynchronously, 
after  updates  have  committed  in  a  source  database,  or  have  been  completed  in  some  other 
data  source.  Processing  triggers  asynchronously  avoids  slowing  down  update 
transactions  with  trigger  processing  logic.  Moreover,  since  an  ATP  could  be  used  with 
many  different  source  DBMSs,  the  effort  to  develop  the  trigger  processing  code  could  be 
amortized  over  use  with  more  applications.  Really,  an  arbitrary  application  program  can 
be  used  to  transmit  descriptions  of  database  updates  (update  descriptors)  to  the  ATP,  and 
triggers  can  be  processed  on  top  of  these  update  descriptors.  The  ability  to  process 
triggers  based  on  updates  from  many  different  sources  can  help  make  it  economically 
viable  to  implement  sophisticated  trigger  processing  code. 

We  are  currently  developing  an  ATP  called  TriggerMan  as  a  vehicle  for 
investigating  issues  related  to  asynchronous  trigger  processing.  A  simple  subset  of  the 
functionality  discussed  in  this  report  has  been  implemented.  We  are  actively  doing  the 
detailed  design  and  implementation  of  the  more  advanced  features  of  TriggerMan. 

Part  of  the  motivation  for  TriggerMan  has  been  the  surge  in  popularity  of 
asynchronous  replication  features  in  commercial  database  systems.  In  actual  practice,  to 
achieve  replication  of  data  in  a  distributed  DBMS,  most  database  customers  greatly 
prefer  asynchronous  replication  to  a  synchronous  replication  policy  based  on  distributed 
transactions  using  two-phase  commit.  The  reason  for  this  is  that  update  availability  and 
response  time  are  both  better  with  asynchronous  replication.  This  was  a  motivating 
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factor  behind  the  choice  to  move  to  an  external,  asynchronous  trigger  processor,  which 
also  would  avoid  slowing  down  updates.  Furthermore,  as  shall  be  explained  later,  the 
update  capture  mechanism  built  in  to  asynchronous  replication  systems  can  be  used  to 
send  update  descriptors  to  an  ATP. 

With  respect  to  related  research,  many  active  database  systems  have  been  developed, 
including  POSTGRES,  HiPAC,  Ariel,  the  Starburst  rule  system,  A-RDL,  Chimera,  and 
others  [Wido96].  In  addition,  there  has  been  a  notion  of  “de-coupled”  rule 
condition/action  binding  mode  for  some  time,  as  introduced  in  HiPAC  [McAr89]. 
However,  the  implicit  assumption  regarding  de-coupled  rule  condition  evaluation  and 
action  execution  was  that  the  DBMS  itself  would  still  do  the  needed  work.  This  report 
outlines  an  alternative  architecture  that  would  off-load  rule  condition  testing  and  action 
execution  to  a  separate  system. 

Ultimately,  the  proposed  TriggerMan/ATP  architecture  will  provide  an  “active 
information  server”  capability  that  can  support  a  wide  variety  of  applications.  This 
architecture  will  be  able  to  support  different  tasks  that  involve  monitoring  of  information 
sources,  filtering  of  data,  and  selective  propagation  of  information.  TriggerMan  can  be 
used  to  augment  traditional  data  management  applications,  as  well  as  support  new, 
distributed,  heterogeneous  information  systems  applications. 

TriggerMan  will  be  extensible  in  a  number  of  ways,  including  the  ability  to  add  new 
data  sources,  new  data  types,  and  new  temporal  functions.  To  handle  extended  data 
types,  the  approach  used  will  be  similar  to  that  used  in  object-relational  database  systems 
such  as  Informix  Universal  server. 

2.  The  TriggerMan  Command  Language 

Commands  in  TriggerMan  have  a  keyword-delimited,  SQL-like  syntax.  TriggerMan 
supports  the  notion  of  a  connection  to  a  remote  database  or  a  generic  data  source 
program.  A  connection  description  for  a  remote  database  contains  information  about  the 
host  name  where  the  database  resides,  the  type  of  database  system  running  (e.g.  Informix, 
Oracle,  Sybase,  etc.),  the  name  of  the  database  server,  a  userid,  and  a  password.  A  single 
connection  is  designated  as  the  default  connection.  There  can  be  multiple  data  sources 
defined  for  a  single  connection.  Data  sources  can  be  defined  using  this  command: 

define  data  source  [connectionName.jsourceName  [as  localName] 

[  (  attributeList )  ] 

[  propertyName=propertyString, 

propertyName=propertyString  ] 

Suppose  a  connection  “salesDB”  had  been  defined  on  a  remote  database  called 
“sales.”  An  example  data  source  definition  for  the  table  “sale”  in  the  sales  database 
might  look  like  this: 

define  data  source  salesDB.sale  as  sale 

This  command  would  read  the  schema  from  the  salesDB  connection  for  the  “sale” 
table  to  gather  the  necessary  information  to  allow  triggers  to  be  defined  on  that  table. 

Triggers  can  be  defined  using  the  following  command: 
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create  trigger  <triggerName>  [in  setName ]  [-inactive] 
from  fromList 
[on  eventSpec] 

[start  time  timePoint ] 

[end  time  timePoint] 

[calendar  calendarName ] 

[when  condition] 

[group  by  attr-list] 

[having  group-condition] 
do  action 

Triggers  are  normally  eligible  to  run  as  soon  as  they  are  created  if  a  triggering  event 
occurs.  However,  if  the  -inactive  flag  is  specified  the  trigger  remains  ineligible  to  run 
until  it  is  enabled  later  using  a  separate  activate  trigger  command.  The  start  time  and 
end  time  clauses  define  an  interval  within  which  the  trigger  can  be  eligible  to  run.  In 
addition,  the  name  of  a  calendar  object  can  be  specified  as  part  of  a  trigger.  A  calendar 
indicates  “on”  and  “off’  time  periods.  For  example,  a  simple  business  calendar  might 
specify  “on”  periods  to  be  Monday  through  Friday  from  8:00AM  to  5:00PM.  A  trigger 
with  a  calendar  is  only  eligible  to  be  triggered  during  an  “on”  period  for  the  calendar.  In 
addition,  whether  a  trigger  is  eligible  to  be  triggered  is  determined  by  the  logical  AND  of 
the  eligibility  criteria  determined  by  (1)  whether  the  trigger  is  active  or  not,  (2)  whether 
the  current  time  is  between  the  start  time  and  end  time,  and  (3)  whether  the  associated 
calendar  is  in  an  “on”  time  period. 

Triggers  can  be  added  to  a  specific  trigger  set,  otherwise  they  belong  to  a  default 
trigger  set.  The  from,  on,  and  when  clauses  are  normally  present  to  specify  the  trigger 
condition.  Optionally,  group  by  and  having  clauses,  similar  to  those  available  in  SQL 
[Date93],  can  be  used  to  specify  trigger  conditions  involving  aggregates  or  temporal 
functions.  Multiple  remote  tables  (or  other  data  streams)  can  be  referenced  in  the  from 
clause.  This  allows  multiple-table  triggers  to  be  defined. 

An  example  of  a  rule,  based  on  an  emp  table  from  a  database  for  which  a  connection 
has  been  defined,  is  given  below.  This  rule  sets  the  salary  of  Fred  to  the  salary  of  Bob: 

create  trigger  updateFred 
from  emp 

on  update  emp.salary 
when  emp. name  =  “Bob” 

do  execSQL  “update  emp  set  saIary=:NEW.emp. salary  where  emp.name= 
‘Fred’” 

This  rule  illustrates  the  use  of  an  execSQL  TriggerMan  command  that  allows  SQL 
statements  to  be  run  against  data  source  databases.  The  :NEW  notation  in  the  rule  action 
(the  do  clause)  allows  reference  to  new  updated  data  values,  the  new  emp.salary  value  in 
this  case.  Similarly,  :OLD  allows  access  to  data  values  that  were  current  just  before  an 
update.  Values  matching  the  trigger  condition  are  substituted  into  the  trigger  action  using 
macro  substitution.  After  substitution,  the  trigger  action  is  evaluated.  This  procedure 
binds  the  rule  condition  to  the  rule  action. 
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An  example  of  a  more  sophisticated  rule  (one  whose  condition  involves  joins)  is  as 
follows.  Consider  the  following  schema  for  part  of  a  real-estate  database,  which  would 
be  imported  by  TriggerMan  using  define  data  source  commands: 

house(hno,  address,  price,  nno,spno) 
salesperson(spno, name, phone) 
represents(spno,nno) 
neighborhoodfnno, name, location) 

A  rule  on  this  schema  might  be  “if  a  new  house  is  added  which  is  in  a  neighborhood 
that  salesperson  Iris  represents  then  notify  her,”  i.e.: 

create  trigger  IrisHouseAlert 
on  insert  to  house 

from  salesperson  s,  house  h,  represents  r 

when  s.name  =  ‘Iris’  and  s.spno=r.spno  and  r.nno=h.nno 

do  raise  event  NewHouseInIrisNeighborhood(:NEW.h.hno,  :NEW.h. address) 

This  command  refers  to  three  tables.  The  raise  event  command  used  in  the  rule 
action  is  a  special  command  that  allows  rule  actions  to  communicate  with  the  outside 
world  [Hans97].  Application  programs  written  using  a  library  provided  with  TriggerMan 
can  register  for  events.  When  triggers  raise  events,  the  applications  registered  for  the 
events  will  be  notified.  Applications  can  run  on  machines  running  anywhere  on  the 
network  that  is  reachable  from  the  machine  where  TriggerMan  is  running. 

3.  System  Architecture 

The  general  architecture  of  the  TriggerMan  system  is  illustrated  in  Figure  1 .  Each 
box  in  this  diagram  represents  a  system  component.  These  components  can  run  on  the 
same  machine  or  different  machines.  Most  components  are  single  processes.  The 
exception  to  this  is  the  TriggerMan  server  component,  which  has  a  parallel  internal 
structure,  consisting  of  a  number  of  virtual  processors,  or  vprocs.  The  vprocs 
communicate  with  each  other  via  message  passing.  Hence,  the  TriggerMan  server  code 
can  be  made  to  run  with  little  modification  on  shared-memory  multiprocessors,  shared- 
nothing  machines,  and  collections  of  SMP  machines  connected  by  an  interconnect.  The 
first  parallel  implementation  is  designed  to  run  on  an  SMP.  The  vproc  concept  has  been 
used  before  successfully  in  the  implementation  of  parallel  DBMS  software,  such  as  the 
Teradata  system  [Witk93]. 

In  the  current  TriggerMan  system  that  runs  on  an  SMP,  vprocs  are  software  objects 
that  live  in  the  same  address  space.  Each  vproc  owns  multiple  threads,  including: 

•  a  matching  thread  that  processes  update  descriptors  arriving  from  data 
sources  to  see  if  trigger  conditions  are  satisfied, 

•  a  command  server  thread  that  handles  requests  from  client  applications, 
and 

•  rule  action  execution  threads  to  run  rule  actions. 

The  number  of  vprocs  is  normally  made  equal  to  the  number  of  real  processors  in  the 
system.  In  the  current  implementation,  single-table  triggers  are  allocated  to  different 
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vprocs  in  a  round-robin  fashion  to  allow  parallel  condition  testing.  A  special  client 
application  called  the  Console  allows  a  user  to  start  the  system,  shut  down  the  system, 
create  triggers,  define  data  sources,  and  run  other  commands  supported  by  TriggerMan. 
Multiple  threads,  spread  across  the  vprocs,  allow  parallel  testing  of  trigger  conditions  on 
an  SMP  machine. 

Two  libraries  that  come  with  TriggerMan  allow  writing  of  client  applications  and 
data  source  programs.  These  libraries  define  the  TriggerMan  client  application 
programming  interface  (API)  and  the  TriggerMan  data  source  API  The  console 
program  and  other  application  programs  use  client  API  functions  to  connect  to 
TriggerMan,  issue  commands,  register  for  events,  and  so  forth.  Data  source  programs, 
such  as  a  generic  data  source  that  sends  a  stream  of  update  descriptors  to  TriggerMan,  or 


Figure  1  Architecture  of  the  TriggerMan  asynchronous  trigger  processor. 

a  DBMS  gateway  program  that  gathers  updates  from  a  DBMS  and  sends  them  to 
TriggerMan,  can  be  written  using  the  data  source  API. 


4.  Data  Source  Design 

A  flexible  strategy  is  being  designed  to  gather  streams  of  update  descriptors  or  other 
messages  from  data  sources.  A  simple,  generic  data  source  could  be  an  application  that 
sends  a  stream  of  new  data  values  to  TriggerMan.  Such  a  generic  data  source,  as 
illustrated  in  Figure  1,  would  be  a  program  written  using  the  data  source  API.  A  more 
sophisticated  data  source  could  gather  a  stream  of  update  descriptors  from  a  database  by 
cooperating  with  the  replication  services  provided  by  the  DBMS.  E.g.  with  Sybase,  a 
gateway  program,  as  shown  in  Figure  1,  could  be  written  using  the  TriggerMan  data 
source  API  and  the  Sybase  replication  API  [Syba96].  This  Gateway  program  would 
transmit  update  descriptors  received  from  the  Sybase  replication  server  and  propagate 
them  to  TriggerMan.  A  different  gateway  program  could  be  written  for  each  potential 
DBMS  that  might  serve  as  a  data  source.  For  databases  for  which  no  replication  service 
exists,  a  gateway  program  could  be  written  that  would  query  the  database  periodically 
and  compare  the  answers  to  the  queries  to  produce  update  descriptors  to  send  to 
TriggerMan  [Chaw96],  Alternatively,  the  gateway  could  trap  inserts,  updates  and  deletes 
using  simple  triggers  in  the  source  DBMS.  Reading  the  database  log  is  another 
alternative,  but  it  is  not  usually  realistic  because  DBMS  vendors  normally  have  a 
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proprietary  log  format  that  other  systems  are  not  allowed  to  read,  since  the  vendor 
reserves  the  right  to  change  the  log  format. 

TriggerMan  will  maintain  catalogs  and  other  persistent  state  information  using  a 
transactional  DBMS.  To  preserve  transaction  semantics,  the  first  approach  to  handling 
the  stream  of  updates  from  a  DBMS  will  be  to  apply  the  updates  in  TriggerMan,  and  run 
the  resulting  trigger  actions,  in  commit  order.  The  Sybase  replication  server,  for 
example,  presents  updates  in  commit  order,  making  this  strategy  feasible.  The  maximum 
transaction  ID  handled  so  far  by  TriggerMan  will  be  recorded  along  with  updates  to 
TriggerMan’s  internal  state  information  in  a  single  transaction.  If  this  transaction  fails, 
the  updates  will  be  rolled  back  and  will  be  re-applied  later.  Maintaining  the  maximum 
transaction  ID  applied  so  far  will  make  sure  TriggerMan  does  not  forget  to  handle  a 
transaction  from  the  primary  database. 

An  issue  that  will  be  addressed  in  the  future  is  how  to  deal  with  high  update  rates  in 
the  data  source  databases.  If  updates  are  taking  place  at  a  high  rate  in  the  source  DBMS, 
TriggerMan  might  not  be  able  to  keep  up  with  the  source  if  it  must  handle  the  updates  in 
commit  order.  This  is  because  it  might  not  be  possible  to  get  enough  concurrency  or 
parallelism  in  the  ATP  if  the  updates  are  handled  serially.  Possible  solutions  to  this 
problem  will  be  considered,  such  as  relaxing  the  requirement  to  handle  updates  in 
commit  order  (for  database  data/data  sources)  or  in  the  order  of  arrival  (for  generic  data 
sources).  Piggybacking  multiple  update  descriptors  in  a  single  message  to  the 
TriggerMan  server  and  in  a  single  broadcast  to  the  vprocs  may  also  make  it  possible  to 
handle  higher  update  rates. 

5.  Temporal  Trigger  Support 

Temporal  triggers  are  triggers  whose  conditions  are  based  on  changes  in  a  value  or 
set  of  values  over  time.  For  example,  a  temporal  trigger  could  be  defined  to  fire  if  the 
sales  from  a  particular  store  rise  by  more  than  20%  in  one  month.  Prior  work  on 
temporal  triggers  has  focused  on  logic-based  trigger  languages  [Sist95].  The  difficulty 
with  these  languages  is  that  the  user  must  specify  the  trigger  in  a  logic-based  notation, 
and  logic-based  languages  with  quantifiers  may  be  difficult  for  typical  application 
developers  to  master.  Moreover,  certain  kinds  of  temporal  conditions  may  be  quite 
useful,  yet  be  extremely  difficult  or  impossible  to  specify  using  temporal  logic.  For 
example,  one  might  envision  a  temporal  trigger  that  would  fire  if  the  price  of  a  stock  had 
a  “spike”  in  value,  where  the  definition  of  “spike”  is  based  on  some  application-specific 
mathematical  criteria,  such  as  “the  average  root  mean  square  difference  on  a  point-by¬ 
point  basis  between  the  actual  sequence  of  values  (curve)  and  an  ideal  spike  is  less  than  a 
threshold  value.”  An  example  of  an  ideal  spike  and  what  an  observed  spike  might  look 
like  is  given  below: 
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The  capability  to  detect  a  spike  based  on  mathematical  criteria  would  be  much  easier 
to  express  using  an  algorithmic  language  like  C,  C++,  Java,  or  FORTRAN  than  using 
temporal  logic.  Moreover,  temporal  functions  written  in  C,  for  example,  may  be  able  to 
evaluate  temporal  trigger  conditions  much  more  efficiently  than  the  equivalent  temporal 
logic-based  condition  evaluator. 

Rather  than  use  a  temporal-logic-based  language,  we  propose  to  use  a  set  of  basic 
temporal  functions,  including  increase,  decrease  and  several  others,  as  well  as  temporal 
aggregates  such  as  the  sum  and  count  of  values  over  a  certain  time  window.  The  benefit 
of  using  temporal  operators  to  specify  trigger  conditions  is  that  they  are  declarative,  and 
relatively  simple  to  understand  -  you  say  what  you  want,  not  now  to  achieve  it.  The 
implementation  of  the  basic  temporal  functions  will  be  provided  as  a  standard  part  of  the 
system.  In  addition,  a  temporal  function  extensibility  mechanism  is  being  developed  to 
allow  sophisticated  application  developers  to  write  code  to  implement  new  temporal 
functions  and  register  this  code  with  the  TriggerMan  system.  The  extension  code  will  be 
dynamically  linked  by  the  TriggerMan  server  when  needed. 

As  mentioned  earlier,  the  TriggerMan  trigger  language  supports  temporal  condition 
specification  through  the  use  of  the  group  by  and  having  clauses  familiar  to  users  of 
SQL.  For  example,  the  following  trigger  will  fire  when  there  is  an  increase  or  decrease  of 
more  than  20%  in  the  price  of  IBM  stock  in  a  six  month  period. 

create  trigger  BigIBMchange 
from  stock 

when  stock.symbol  =  “IBM” 
having  increasefstock. price,  “20%”,  “6  mo”)  or 
decreasefstock. price,  “20%”,  “6  mo”) 
do  raise  event  BigChange  (“IBM”) 

The  above  trigger  can  be  generalized  to  all  “technology”  stocks  by  introducing  a 
group  by  clause  and  modifying  the  when  clause,  as  follows: 

create  trigger  BigTechStockChange 
from  stock 

when  stock.category  =  “technology” 
group  by  stock.symbol 

having  increase(stock.price,  “20%”,  “6  mo”)  or 
decrease(stock.price,  “20%”,  “6  mo”) 
do  raise  event  BigChange  (:NEW.stock.symbol) 

The  group  by  capability  is  powerful  since  it  allows  triggers  for  multiple  groups  to  be 
defined  using  a  single  statement. 

Temporal  functions  can  return  boolean  values  (temporal  predicates)  and  scalar 
values,  such  as  integers  and  floating  point  numbers.  These  types  of  temporal  functions 
can  be  composed  in  the  having  clause  to  form  compound  temporal  conditions.  For 
example,  the  following  temporal  function  might  compute  a  moving  average  of  a  value 
over  a  time  window  of  width  window_size: 
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moving_avg  (expr,window_size) 

The  following  example  shows  how  this  function  could  be  used  in  conjunction  with 
the  increase  function  to  detect  when  the  10-day  moving  average  of  the  price  of  Oracle 
stock  increases  by  more  than  15%: 

create  trigger  ORACLE_TREND 
from  stock 

when  stock.symbol  =  “ORCL” 

having  increase(moving_avg(stock.price,  “10  days”),  “15%”) 
do  ... 

Values  of  temporal  aggregates  computed  in  the  having  clause  will  sometimes  need 
to  be  used  in  the  trigger  action.  The  trigger  language  needs  a  way  to  support  this  form  of 
condition/action  binding.  When  it  is  not  ambiguous,  the  name  of  the  temporal  aggregate 
function  can  be  used  in  the  trigger  action,  as  in  the  following  example: 

create  trigger  HighYearlySales 
from  sale 

group  by  sale.spno 

having  sum(sale.amount,  “1  yr”)  >  1000000 

do  execSQL  “append  to  highSales(:NEW.sale.spno,  :NEW.sum,  Date())” 

If  the  same  function  appears  multiple  times,  the  as  operator  can  be  used  to  bind 
names  to  the  values  produced  by  those  functions,  e.g.: 

create  trigger  HighSalesAndCommssions 
from  sale 

group  by  sale.spno 

having  sum(sale.amount,  “1  yr”)  as  si  >  500000 
and  sum(sale.commission,  “1  yr”)  as  s2  >  50000 
do  execSQL  “append  to  highSales(:NEW.sale.spno,  :NEW.sl,  :NEW.s2, 

Date())” 

5.1.  Adding  New  Temporal  Functions 

The  temporal  function  mechanism  in  TriggerMan  is  designed  to  be  extensible.  A 
new  temporal  operator  can  be  defined  using  this  notation: 

define  temporal  function  retumType  funcName  (argumentDefinition) 
dynamicLinkLibraryName  functionPrefix 

The  dynamicLinkLibraryName  is  the  name  of  the  dynamic  link  library  (DLL)  where 
relevant  functions  are  kept.  The  DLL  consists  of  compiled  C  code.  The  functionPrefix 
is  the  prefix  of  the  name  of  all  functions  that  are  relevant  to  the  temporal  operator  being 
defined.  A  temporal  function’s  argument  list  can  specify  normal  arguments,  as  well  as 
initialization  arguments  used  to  initialize  the  state  of  the  temporal  function.  Initialization 
arguments  are  preceded  by  the  keyword  init.  A  default  value  can  also  be  provided  for 
init  arguments.  For  example,  a  new  function  to  compute  an  exponential  average  could  be 
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registered  with  the  system  like  this  (the  C:\tmanlib\expavg.dll  file  is  a  dynamic  link 
library): 


define  temporal  function  double  expavg  (double  newValue, 
init  double  multiplier  =  0.9)  “C:\tmanlib\expavg.dll”  “double_expavg” 


Also,  functions  can  be  overloaded.  For  example,  expavg  can  be  re-implemented  for 
different  types,  such  as  float,  and  the  system  will  automatically  use  the  right  function 
depending  on  the  data  types  with  which  it  is  called. 

Functions  with  the  proper  formats  and  naming  conventions  need  to  be  available  in 
the  dynamic  link  library  to  implement  a  temporal  function.  This  kind  of  extensibility 
technique  is  similar  to  that  used  in  extensible  database  systems  such  as  POSTGRES 
[Ston90]  and  the  Informix  Universal  Server  [Info97].  To  test  the  condition  of  a  temporal 
trigger,  state  information  related  to  the  temporal  trigger  condition  must  be  maintained. 
For  example,  state  could  simply  be  a  number  and  a  multiplier  for  a  simple  exponential 
average.  For  most  temporal  triggers  involving  temporal  aggregates  such  as  increase, 
decrease  etc.,  the  state  of  the  trigger  will  be  a  time  series.  In  addition,  if  there  is  a  group 
by  clause,  one  piece  of  state  information  (normally  a  time  series)  must  be  maintained  for 
each  group.  The  functions  required  in  the  DLL  used  to  implement  a  temporal  operator 
must  be  able  to  create  a  temporal  trigger  state  object,  delete  the  object,  update  the  state  of 
the  object  based  on  the  arrival  of  new  data  or  the  passage  of  time,  and  get  the  current 
value  of  the  temporal  operator. 

We  use  the  C  language  to  define  the  interface  to  a  temporal  operator’s  state  object. 
C  is  used  instead  of  C++  or  Java  [Arno96]  because  (1)  we  want  very  high  performance, 
meaning  that  fully  compiled  code  is  required,  ruling  out  Java,  and  (2)  because  dynamic 
linkers  in  Windows  NT  and  Solaris  (Sun  Unix)  support  dynamic  linking  of  C  much  better 
than  dynamic  linking  of  C++.  In  addition,  we  provide  a  reusable  time-series  abstract  data 
type  implemented  in  C  for  use  by  developers  of  new  temporal  functions,  as  well  as  for 
our  own  internal  use. 

Full  details  of  the  formats  of  the  C  functions  required  in  a  DLL  to  define  the 
behavior  of  a  temporal  operator  are  not  given  here.  A  general  description  of  the 
functions  required  (but  not  a  complete  list)  is  as  follows: 


constructor 


destructor 


provide  new 
history  value 

provide  new 
current  time 
value 


A  function  to  build  the  internal  state  object  for  a  temporal  trigger 
(or  a  single  group  of  a  temporal  trigger  in  case  a  group  by  clause 
is  used).  Usually  the  state  object  will  contain  a  time  series. 

A  function  to  free  the  space  used  by  a  temporal  trigger  state 
object  when  it  is  no  longer  needed  (e.g.  when  a  trigger  is 
dropped). 

A  function  to  take  a  new  value  and  time  stamp  to  update  the 
history  information  (usually  a  time  series)  contained  in  the  state 
object 

A  function  to  provide  a  new  value  of  the  current  time.  This  can 
be  thought  of  as  a  “clock  tick”  function.  The  state  object  should 
be  updated  as  needed  based  on  this  new  time  value  (e.g.  to  trim 
off  some  of  the  oldest  history  values  that  have  moved  out  of  the 
time  window  of  interest).  This  function  will  be  called 
periodically  for  some  operators,  such  as  “holds(emp.salary, 
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“>30000”,  “2  years”)”.  With  “holds”  and  some  other  temporal 
operators,  it  may  be  necessary  to  fire  even  if  no  new  history  value 
arrives. 

get  current  Get  the  current  value  of  the  temporal  operator  (the  result  may  be 

value  true/false  or  some  other  data  type). 

A  protocol  for  firing  temporal  triggers  needs  to  support  both  triggering  when  update 
events  occur,  and  triggering  when  timers  expire.  The  interface  above  allows  TriggerMan 
to  trigger  both  on  update  events  and  on  timer  expiration,  as  needed. 

6.  Support  for  Multiple-Table  and  Parallel  Trigger 
Condition  Testing 

Allowing  triggers  to  have  conditions  based  on  multiple  tables  greatly  increases  the 
power  and  expressiveness  of  the  trigger  language.  However,  efficiently  testing  multiple- 
table  trigger  conditions  is  a  challenging  problem.  As  part  of  prior  work,  we  have 
developed  an  optimized  multiple-table  trigger  condition  testing  mechanism  known  as  the 
Gator  network,  a  generalization  of  the  TREAT  and  Rete"  networks  used  for  rule  condition 
testing  in  production  rule  systems  such  as  OPS5  [Hans95].  We  are  investigating 
strategies  that  will  allow  development  of  a  parallel  version  of  the  Gator  network,  as  well 
as  cost  models  and  caching  strategies  specific  to  the  environment  of  an  asynchronous 
trigger  processor.  These  new  cost  models  and  caching  strategies  are  needed  since 
TriggerMan  runs  in  an  separate  address  space  and  possibly  on  a  separate  machine  from 
the  DBMS  or  other  data  sources. 

A  parallel  Gator  network  capability  will  be  developed  for  TriggerMan  to  allow 
multiple  table  rule  condition  testing.  A  related  approach  has  been  successfully  used  to 
perform  parallel  rule  condition  matching  in  main-memory  production  systems  using  a 
Rete  network  [Forg82]  organized  as  a  global  distributed  hash  table,  or  GDHT  [Acha92]. 
The  idea  behind  this  strategy  is  as  follows.  A  Gator  network  tree  structure  will  be 
constructed  for  each  trigger.  Gator  networks  consist  of  nodes  to  test  selection  and  join 
conditions,  plus  “memory”  nodes  that  hold  sets  of  tuples  matching  one  or  more  selection 
and  join  conditions.  For  example,  consider  the  following  table  schemas,  trigger 
definition,  and  one  possible  Gator  network  for  the  trigger: 

reln=Rl  reln=R2  reln=R3 


Rl.a=“x”  j  | 

memory  1  memory2  memory2 


R2.r3no=R3.r3no 


Rl(rlno,a,b) 

R2(rlno,r3no) 

R3(r3no,c,d) 

create  trigger  T1 
from  Rl,  R2,  R3 
when  Rl.rlno=R2.rlno 
and  R2.r3no=R3.r3no 
and  Rl.a  =  “x” 
then  do  ... 
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In  this  Gator  network,  memory  1  logically  contains  the  result  of 
select  *  from  R1  where  Rl.a=  “x” 

Similarly,  memory4  logically  contains  the  result  of 

select  *  from  Rl,  R2  where  Rl.a  =  “x”  and  Rl.rlno=R2.rlno 

In  addition,  memory  nodes  can  be  either  stored  or  virtual.  A  stored  node  is  like  a 
materialized  view.  It  actually  contains  the  specified  tuples.  A  virtual  node  is  like  a  real 
view.  It  only  contains  a  predicate  defining  which  tuples  should  qualify.  It  does  not 
contain  the  real  tuples.  Memory  nodes  at  the  leaf  level,  drawn  at  the  top  of  a  Gator 
network,  are  called  alpha  memory  nodes.  Inner  memory  nodes,  holding  join  results,  are 
called  beta  memory  nodes.  Only  alpha  memory  nodes  can  be  virtual. 

A  detailed  discussion  of  how  discrimination  networks  can  be  used  for  multiple-table 
trigger  condition  testing  on  a  single  processor  can  be  found  in  [Hans96],  An  outline  of 
our  approach  to  implementing  a  Gator  network  in  parallel  on  a  shared-nothing  machine 
consisting  of  a  set  of  vprocs  is  as  follows: 

1.  The  selection  predicates  will  be  allocated  round-robin  among  the  processors. 

2.  The  tree  shape  of  the  network  will  be  replicated  on  every  vproc.  The  contents 
of  alpha  and  beta  nodes  will  not  be  replicated. 

3.  Stored  memory  nodes  will  be  horizontally  partitioned  across  the  vprocs  on  a 
single  attribute,  normally  a  join  attribute,  using  hash  partitioning. 

4.  Stored  memory  nodes  will  be  cached  in  their  entirety  in  memory  in  TriggerMan 
on  first  use.  Virtual  memory  nodes  will  never  be  cached.  An  LRU  replacement 
strategy  will  be  used  with  an  entire  memory  node  as  the  cache  replacement 
granularity.  (More  sophisticated  caching  policies  that  allow  caching  a  subset  of 
a  memory  node  are  being  considered). 

5.  For  other  attributes  for  which  a  fast  access  path  is  required  to  a  memory  node, 
such  as  additional  join  attributes  or  the  primary  key,  parallel  secondary  hash 
partitions  will  be  created.  These  are  analogous  to  secondary  indexes  in  a  single- 
processor  DBMS.  For  a  memory  node  Nfnno.  X,  ...)  if  the  node  has  a  primary 
partition  on  X,  then  a  secondary  partition  on  the  nno  (primary  key)  field  can  be 
formed  by  creating  a  table  N_nno_index(nno,vproc_number)  and  doing  a 
primary  hash  partition  of  N_nno_index  on  nno.  A  row  in  N_nno_index  tells 
which  vproc  contains  the  tuple  with  a  particular  value  of  nno.  This  allows 
deletion  of  a  tuple  in  N  given  its  key  (nno)  value  with  two  point-to-point 
messages,  one  to  look  up  the  processor  where  the  tuple  lives  using 
N_nno_index,  and  one  to  actually  delete  the  tuple. 

6.  Pattern  matching  will  operate  as  follows: 

a.  When  a  tuple  update  arrives,  a  description  of  the  update  will  be  packaged  as 
a  “token”  and  will  be  broadcast  to  all  the  vprocs.  A  token  contains  a  tuple 
or  an  old/new  tuple  pair,  along  with  a  tag  describing  what  kind  of  operation 
was  performed  (insert,  delete  or  update).  If  the  operation  is  an  update,  then 
the  identification  of  which  fields  were  updated  will  also  be  included  in  the 
token. 

b.  Each  vproc  will  test  the  token  against  its  local  collection  of  selection 
predicates.  Event  conditions  from  the  on  clause  and  regular  selection 
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conditions  from  the  when  clause  will  both  be  treated  logically  as  selection 
conditions  on  tokens. 

c.  For  each  matching  selection  predicate,  the  token  will  be  forwarded  onward 
down  the  network.  For  a  single-table  trigger,  a  match  against  the  selection 
predicate  for  the  trigger  causes  the  trigger  action  to  fire.  The  trigger  action 
is  executed  once  for  each  matching  tuple,  on  the  processor  where  the  match 
is  detected. 

d.  For  a  multiple-table  trigger,  a  match  of  a  token  against  a  selection  predicate 
causes  an  update  to  the  memory  node  below  the  selection  predicate,  and 
then  the  token  is  joined  to  a  neighboring  memory  node  (see  below  for  a 
discussion  of  parallel  joins  of  tokens  to  memory  nodes).  Resulting  joining 
pairs  of  tuples  (intermediate  tokens)  are  then  propagated  down  the  network. 
When  a  token  arrives  at  the  bottom  of  the  network  (the  P-node)  the  trigger 
action  is  run  for  that  token. 

In  general,  the  following  operations  may  need  to  be  performed  on  a  memory  node: 
(1)  insert  a  tuple,  (2),  delete  a  tuple  and  (3)  join  a  tuple  to  the  node.  Each  of  these 
operations  can  be  performed  using  one  or  two  point-to-point  messages  from  one  vproc  to 
another  based  on  the  hash  partitioning  scheme  used.  Consider  memory2  from  the  Gator 
network  shown  earlier.  Tuples  may  need  to  be  inserted  into  or  deleted  from  memory2. 
In  addition,  a  tuple  may  sometimes  be  joined  to  memory2.  This  requires  finding  all  the 
memory2  tuples  such  that  memory2.rlno=CONSTANT  for  some  constant  value 
extracted  from  the  rlno  field  of  the  tuple  being  joined  to  memory2.  In  this  example, 
memory2  would  be  hash  partitioned  across  the  vprocs  on  the  rlno  column.  Hence,  to 
find  all  memory2  tuples  satisfying  memory2.rlno  =  CONSTANT,  a  vproc  must  do  the 
following.  First,  use  the  hash  function  h  used  to  define  the  partition  of  memory2  to  find 
h(CONSTANT),  yielding  a  value  P,  a  vproc  number.  Any  memory2  tuples  that  join  to 
the  current  tuple  must  be  stored  on  vproc  P  due  to  the  way  memory2  is  partitioned.  Send 
the  tuple  being  joined  to  memory2  to  vproc  P.  The  join  can  them  be  completed  locally 
on  vproc  P. 

An  additional  issue  is  how  to  deal  with  non-equijoins.  These  are  joins  for  which  the 
join  predicate  is  something  other  than  the  =  operator.  For  example,  the  following  trigger 
has  a  non-equijoin  condition: 

create  trigger  NonEquiJoinExample 
from  Rl,  R2 

when  Rl.X  >=  R2.1owerBound  and  R1.X  <  R2.upperBound 
do ... 

For  triggers  like  this,  it  is  not  possible  to  define  a  partitioning  that  can  be  used 
effectively  to  speed  up  join  processing.  Hence,  in  cases  like  this,  broadcasts  will  be  used 
to  join  a  token  to  a  memory  node  in  parallel.  Memory  nodes  will  still  be  horizontally 
partitioned. 

It  is  a  good  idea  to  avoid  broadcasts  and  use  a  point-to-point  messaging  scheme 
instead  when  possible.  This  will  avoid  unnecessary  CPU  utilization.  With  point-to-point 
messaging,  a  parallel  speedup  can  still  be  obtained  because  multiple  tokens  can  be 
processed  simultaneously  on  different  processors. 
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We  have  outlined  the  basic  pattern  matching  strategy  for  select/join  trigger 
conditions.  Fully  detailed  algorithms  for  all  aspects  of  join  condition  testing  and 
temporal  condition  testing  are  left  for  a  future  paper. 

7.  Extensibility 

TriggerMan  is  designed  to  be  extensible.  This  will  include  support  for  new  data 
types  and  operators,  in  addition  to  new  temporal  functions.  Support  for  extended  data 
types  such  as  images,  time  series,  web  pages,  text,  etc.  within  a  database  management 
system  has  been  supported  in  POSTGRES  [Ston90]  and  Informix  Universal  Server 
[Info97]  and  is  being  included  in  other  commercial  database  products.  This  feature  is 
beginning  to  be  used  to  add  multimedia  and  object  management  capability  to  real-world 
database  applications.  The  approach  taken  to  support  extensibility  has  been  to  define  a 
dynamic  link  library  of  C  functions  with  a  certain  format,  including  (1)  constructor  and 
destructor  functions,  (2)  functions  for  translating  an  instance  of  a  type  from  internal  to 
external  format,  (3)  functions  for  performing  operations  on  instances  of  a  type,  (4) 
functions  for  estimating  the  cost  of  performing  certain  operations,  etc.  This  library  is 
then  registered  with  the  DBMS  and  dynamically  linked  when  needed.  As  an  example,  an 
extended  data  type  called  Document  could  be  created,  and  triggers  could  be  defined  on  a 
stream  of  documents  arriving  from  an  intelligence-gathering  source,  implementing  a  form 
of  selective  dissemination  of  information  using  TriggerMan. 

If  possible,  the  approach  to  handling  extended  data  types  in  TriggerMan  will  be  to 
use  the  standard  extensibility  format  used  by  Informix,  and  introduce  commands  to 
register  new  types  with  the  system.  If  this  is  done,  the  same  DataBlade  modules  used  by 
Informix  can  be  used  by  TriggerMan.  Using  the  existing  Informix  type  extension 
standard  in  TriggerMan  is  preferred  to  defining  a  new  standard  for  extended  types,  since 
existing  extended  types  that  have  already  been  implemented  for  Informix  could  be  used 
with  TriggerMan.  However,  we  will  define  our  own  type  extension  module  format  if 
necessary.  As  part  of  the  TriggerMan  project,  issues  related  to  moving  large  objects 

between  a  DBMS  and  TriggerMan,  caching  the  internal  representation  of  large  objects, 
and  evaluating  expensive  predicates  within  the  TriggerMan  server  will  be  investigated. 

8.  Performance  of  Initial  Prototype 

A  version  of  the  prototype  TriggerMan  server,  consisting  of  roughly  20,000  lines  of 
C++,  is  already  operational.  It  implements  single-table  triggers,  but  has  no  persistent 
catalogs  or  ability  to 
directly  communicate 
with  a  DBMS  via  a 
replication  server 

gateway.  It  supports 

parallelism  using  the 
concept  of  virtual 

processors  (vprocs), 
making  the  code 

portable  to  both  SMP 
and  shared-nothing  parallel  computers.  Performance  tests  were  run  on  a  dual-processor 


for  {set  i  2}  {$i  <=  2700}  { incr  i  2 }  { 
createTrigger  t$i  in  tsl  { 
from  EMPLOYEE 
on  {insert  EMPLOYEE) 

when  { EMPLOYEE. salary  =  [expr  2700  %  $i]} 
do  {}}  #  no  trigger  action  was  run  so  only 
}  #  condition  testing  would  be  timed 


14 


75Mhz  Sun  SPARCstation  20.  Originally,  the  TriggerMan  command  language  was 
implemented  as  an  extension  of  Tel.  We  have  since  implemented  a  command-language 
parser  so  Tel  is  not  a  required  component  of  TriggerMan,  and  commands  have  a  more 
natural,  SQL-like  syntax.  At  the  time  the  tests  were  done,  the  createTrigger  command 
was  implemented  as  an  extended  Tel  command.  The  performance  tests  were  done  in  the 
following  manner.  A  single  EMPLOYEE  data  source  was  defined.  A  total  of  1350 
triggers  were  then  created  using  the  Tel  program  shown  inset. 

The  triggers  created  fire  when  the  inserted  employee  has  a  salary  equal  to  some 
constant.  The  [expr  2700  %  $i]  expression  is  evaluated  before  the  trigger  is  created.  The 
%  symbol  is  the  modulo  operator.  There  are  24  triggers  that  will  fire  when  the  inserted 
salary  is  zero.  Triggers  are  allocated  round-robin  to  the  different  vprocs.  The  tests  were 
run  first  with  one  vproc,  then  with  two.  With  one  vproc,  only  one  of  the  processors  is 
used  for  rule  condition  testing.  With  two,  both  processors  are  used.  The  results  are 
summarized  in  the  following  table: 


Number  of  Processors 

Average  Condition  Testing 

Average  Condition  Testing 

Used  (number  of  vprocs). 

Time  for  All  Triggers 

Time  Per  Trigger 

1 

13.5  msec 

10  psec 

2 

7.5  msec 

5.6  psec 

No  selection  predicate  indexing  strategy  [Hans90,Hans96b]  is  currently  used.  A 
selection  predicate  index  could  dramatically  increase  performance  for  this  example.  This 
example  shows  that  performance  will  be  quite  good  for  single  data  source  triggers  even 
when  their  conditions  are  not  or  cannot  be  indexed,  as  long  as  the  number  of  triggers  is 
not  huge. 

The  TriggerMan  code  is  now  being  ported  to  Windows  NT,  which  will  become  our 
primary  development  platform.  Code  will  be  written  in  a  way  so  that  the  system  will  be 
portable  to  NT  and  Solaris.  Access  to  a  database  for  storing  TriggerMan’s  catalog 
information  and  other  persistent  state  will  be  done  using  the  ODBC  interface  so  that 
TriggerMan  will  work  with  multiple  different  DBMS  products. 

9.  Conclusion 

The  research  outlined  here  seeks  to  develop  principles  that  will  allow  the  effective 
construction  of  asynchronous,  or  “outboard”  trigger  processing  systems.  A  prototype 
ATP  called  TriggerMan  is  being  implemented  as  a  vehicle  to  explore  asynchronous 
trigger  processing  issues  and  to  validate  the  design  approach  introduced  here. 
TriggerMan,  or  a  system  like  it,  could  be  useful  in  situations  where  current  trigger 
systems  are  not.  For  example,  TriggerMan  could  trigger  on  a  stream  of  updates 
generated  by  a  general  application  program  that  were  never  placed  in  any  DBMS. 
Moreover,  TriggerMan  could  place  a  trigger  on  two  different  data  sources,  one  from  a 
DBMS,  and  one  from  a  program,  performing  an  information  fusion  function.  This  type 
of  function  could  be  valuable  in  a  number  of  heterogeneous  information  systems 
applications,  e.g.,  in  a  chemical  plant  application,  a  trigger  could  correlate  a  stream  of 
reactor  vessel  temperature  and  pressure  values  sent  by  an  application  with  known 
dangerous  combinations  of  temperature  and  pressure  kept  in  a  database,  firing  when  it 
saw  a  dangerous  combination.  The  main  benefit  of  an  ATP  system  is  that  it  can  allow 
sophisticated,  “expensive”  triggers  (e.g.  multiple-table  and  temporal  triggers)  to  be 
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defined  against  a  database  and  processed  using  the  best  available  algorithms,  without 
adversely  impacting  on-line  update  processing.  This  could  greatly  expand  the  benefits  of 
trigger  technology  in  demanding,  update-intensive  environments. 

The  results  of  the  TriggerMan  project  could  lead  to  a  new  type  of  system  to  support 
applications  that  need  to  monitor  changes  to  information  -  an  asynchronous  trigger 
processor.  In  addition,  an  architecture  for  asynchronous  trigger  processing  similar  to  the 
one  described  here  could  be  incorporated  directly  into  a  DBMS.  This  would  allow  the 
benefits  of  asynchronous  trigger  processing,  particularly  good  update  response  time  plus 
sophisticated  trigger  processing  capability,  without  the  need  to  incur  the  cost  of  moving 
update  descriptors  across  the  boundary  from  the  DBMS  into  another  system.  In  addition, 
it  would  not  be  necessary  to  cross  back  to  the  DBMS  to  run  trigger  actions  against 
database  data.  In  summary,  the  work  outlined  here  can  help  develop  a  new,  useful  kind 
of  information  processing  tool,  the  ATP,  and  point  the  way  to  improvements  in  the  active 
database  capability  of  existing  database  management  systems.  In  either  case,  it  will 
become  possible  to  develop  powerful  information  monitoring  applications  more  easily, 
and  these  applications  will  run  with  faster  performance. 
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KSC  OPERATIONS 

attn:  mark  maginn 

BEECHES  TECHNICAL  CAMPUS/RT  26  N. 
ROME  NT  13440 

NAVAL  POSTGRADUATE  SCHOOL 
ATTN:  BALA  RAMESH 

CODE  AS/RS 

ADMINISTRATIVE  SCIENCES  DEPT 
MONTEREY  CA  93943 

HUGHES  AIRCRAFT  COMPANY 
ATTN:  GERRY  BARKSDALE 

P.  0.  BOX  3310 
BLDG  618  MS  E215 
FULLERTON  CA  92634 

SCHLUM3ER  GER  LABOR  ATORY  FOR 
COMPUTER  SCIENCE 
ATTN:  DR.  GUILLERMO  ARANGO 

8311  NORTH  FM620 
AUSTIN,  TX  78720 

MOTOROLA,  INC. 

ATTN:  MR.  ARNOLD  PITTLER 

3701  ALGONQUIN  ROAD,  SUTE  601 
ROLLING  MEADOWS,  IL  60008 


DECISION  SYSTEMS  DEPARTMENT 
ATTN:  PROF  WALT  SCACCHI 

SCHOOL  OF  BUSINESS 

UNIVERSITY  OF  SOUTHERN  CALIFORNIA 
LOS  ANGELES,  CA  90089-1421 


SOUTHWEST  RESEARCH  INSTITUTE 
ATTN:  SRUCE  REYNOLDS 

6220  CULESRA  ROAD 
SAN  ANTONIO*  TX  73228-0510 


NATIONAL  INSTITUTE  OF  STANDARDS 
AND  TECHNOLOGY 
ATTN:  CHRIS  DASROWSKI 

ROOM  A266 »  3L0G  225 
GAITHSBURG  MO  20899 

EXPERT  SYSTEMS  LABORATORY 
ATTN:  STEVEN  H.  SCHWARTZ 

NYNEX  SCIENCE  &  TECHNOLOGY 
500  WESTCHESTER  AVENUE 
WHITE  PLANS  NY  20604 

NAVAL  TRAINING  SYSTEMS  CENTER 
ATTN:  ROBERT  BRE AUX/COOE  252 

12350  RESEARCH  PARKWAY 
ORLANDO  FL  32826-3224 


CENTER  FOR  EXCELLENCE  IN  COMPUTER- 
AIDED  SYSTEMS  ENGINEERING 

attn:  perry  Alexander 

2291  IRVING  HILL  ROAD 
LAWRENCE  KS  66049 

DR  JOHN  SALASIN 

qarpa/ito 

3701  NORTH  FAIRFAX  ORIVE 
ARLINGTON  VA  22203-1714 


DR  BARRY  BOEHM 

OIR »  USC  CENTER  FOR  SW  ENGINEERING 

COMPUTER  SCIENCE  DEPT 

UNI V  OF  SOUTHERN  CALIFORNIA 

LOS  ANGELES  CA  90089-0791 

DR  STEVE  CROSS 
CARNEGIE  MELLON  UNIVERSITY 
SCHOOL  OF  COMPUTER  SCIENCE 
PITTSBURGH  PA  15213-3891 


DR  MARK  MAYBURY 
MITRE  CORPORATION 
ADVANCED  INFO  SYS  TECH;  S041 
3URLINT0N  ROAD*  M/S  K-329 
BEDFORD  MA  01730 


DL-8 


1 


MR  SCOTT  FOUSE 
ISX 

4353  PARK  TERRACE  DRIVE 
WESTLAKE  VILLAGE  C  91361 


MR  GARY  EDWARDS  1 

ISX 

433  PARK  TERRACE  DRIVE 
WESTLAKE  VILLAGE  CA  91361 


OR  ED  WALKER  1 

B8N  SYSTEMS  &  TECH  CORPORATION 
10  MOULTON  STREET 
CAMBRIDGE  MA  02238 


LEE  ERMAN  1 

CIMFLEX  TEKNOWLEDGE 

1810  EM3ACA0ER0  ROAD 

P.0,  SOX  10119 

PALO  ALTO  CA  94303 

DR.  DAVE  GUNNING  1 

DARPA/ISG 

3701  NORTH  FAIRFAX  DRIVE 
ARLINGTON  VA  22203-1714 


DL-9 


